Closing this PR. After review, this fix targets the wrong problem and the change itself has no practical benefit.

Why this doesn't fix #418

Issue #418 is about an RTP multicast upstream (the reporter explicitly confirmed this in a follow-up comment). The RTP path does not go through src/http_proxy.c at all — RTP upstreams don't return HTTP response headers, so there are no "upstream response headers" to forward in the first place. This PR cannot affect the #418 scenario.

The likely root cause of #418 lies elsewhere — most plausibly in Chrome's socket-management behavior under PAC mode, where FIN delivery for "direct" connections may be deferred. The original reporter has also been unable to reproduce since.

Why injecting Connection: close here has no real benefit

For the HTTP proxy path itself, walking through the topology client ↔ V2Ray ↔ rtp2httpd ↔ upstream:

1. After the response completes, worker_close_and_free_connection calls close(fd) (src/worker.c:160), so the TCP connection from rtp2httpd to the downstream proxy is always closed at the TCP layer, regardless of what the HTTP Connection header says.
2. Whether V2Ray keeps its V2Ray ↔ client connection alive is V2Ray's internal business. Even if it does keep-alive that connection:
   • If the client reuses it for a new request, V2Ray must open a new TCP connection to rtp2httpd (the previous one is already closed). rtp2httpd just sees a fresh request — no leaked state, no resource retention.
   • If the client doesn't send a new request, V2Ray's own idle timeout reclaims it. Again, no impact on rtp2httpd.
3. rtp2httpd itself does not support keep-alive (src/http.c:46-50 already forces Connection: close on its own responses), so there's no reuse on rtp2httpd's side either way.

So the worst case is purely a header-cleanliness inconsistency: the request side sends Connection: close but the response side passes through whatever upstream sent. There is no actual resource leak, dangling connection, or correctness issue on the rtp2httpd side.

Conclusion

• Doesn't fix 系统代理环境下连接终止异常 #418 (wrong code path).
• The standalone change is at most a cosmetic HTTP correctness tweak with no observable effect.
• Adds non-trivial response-header rebuilding code on a hot path for no real gain.

Closing as not needed. The actual #418 root cause should be investigated client-side (Chrome NetLog under PAC mode + tcpdump on the rtp2httpd side to see when the client's FIN actually arrives).